Ceph运维实践
在后期生产环境中，Ceph存储会遇到磁盘损坏或物理机硬件问题，本章主要介绍Ceph存储的基础运维操作和高级运维操作。
基础运维实践
以下介绍Ceph存储的基础运维，主要包括Ceph存储扩容和OSD盘替换。
Ceph存储扩容
Ceph存储可通过添加OSD或添加节点两种方式进行扩容，以下分别介绍两种方法的实施步骤。
添加OSD
在后期生产环境中，若整体存储池容量不足，可以通过对所有服务器添加硬盘进行扩容操作。具体步骤参考以下最佳实践。
最佳实践
检查存储是否为健康的状态，若不是健康的状态，请不要进行任何操作，健康的情况如下图所示：
存储节点登录网页后，关闭数据恢复选项。
点击资源管理->存储池，勾选对应存储池。点击操作->添加硬盘。
添加新插入的磁盘。
等待磁盘添加成功，打开恢复模式，等待恢复完成即可。
注意事项
- 请注意存储节点必须全部添加相同的磁盘，防止木桶效应导致存储性能降低。
- 请勿在业务高峰等敏感时期进行操作。
- 确保缓存盘足够容量，若容量不足会导致性能降低。
添加存储节点
Ceph存储可以通过扩容节点来补充云资源池的资源，以下最佳实践以添加存储节点为例介绍扩容步骤。
最佳实践
基本配置：点击资源管理 > 节点 > 添加，在添加节点界面，填写节点IP，并选择节点类型、节点角色，本场景下，节点类型为存储节点、角色为块存储网关角色。点击下一步，完成环境初始化。
配置网络：在配置网络界面，分别填写存储网关网络以及存储网即可。
确认信息：正式安装节点前，检查配置信息是否正确。
安装：确认配置信息正确后，点击添加，开始安装节点。
- 添加完成后，依次添加缓存盘、硬盘，调整拓扑，并将硬盘加入存储池，等待存储池恢复健康状态。
替换OSD盘
在后期生产环境中，会遇到部分磁盘损坏或有坏道的现象，具体表现为在系统中的message提示有坏道，如下图所示：
此时需要进行换盘操作，确保整体数据安全。具体换盘步骤参考以下最佳实践。
最佳实践
关闭云平台全局高可用设置，如下图所示：
检查存储池和存储集群是否处于健康状态，可执行ceph-s命令检查，或登录UI界面查看。 执行ceph -s命令检查：
登录Ceph UI检查：
- 禁止数据恢复。 a) 登录Ceph存储UI界面，点击设置 > 禁止数据恢复。
b) 检查数据恢复是否已被禁止。
将离线OSD盘从存储池移除，下图以osd.4为例。 a) 详细操作步骤：进入目标存储池，点击操作 > 移除硬盘，选择移除离线的OSD。
b) 检查离线硬盘是否已被移除，如下图所示：
将对应硬盘从列表删除
a) 进入硬盘界面，定位对应的物理机硬盘，点击操作 > 删除。
b) 检查硬盘是否已被删除，如下图所示：
c）删除后通知更换硬盘。
在硬盘列表添加新换的盘，等待其初始化完成。
将新盘加到存储池中。
添加完毕后，开启数据恢复，设置为低速恢复，耐心等待数据恢复完毕。
高级运维实践
在后期运维过程中，有可能会遇到存储平台有部分提示，提示的原因需要进入系统内日志了解查询。
以下介绍Ceph存储高级运维实践，主要包括存储池运维和OSD盘运维。
存储池运维
在企业版Ceph存储环境中，可通过ceph-s命令查看ceph集群存储池基本情况。存储池存在以下三种健康状况： HEALTH_OK：存储池正常。 HEALTH_WARN：存储池存在某些异常情况，存储仍可用。对于HEALTH_WARN，有以下提示需要注意。
- MON_DOWN：其中一个节点的mon服务有异常，Monitor 维护着 Ceph 集群的信息，如果 Monitor 无法正常提供服务，那整个 Ceph 集群就不可访问。一般来说，在实际运行中，Ceph Monitor的个数是 2n + 1 ( n >= 0) 个，在线上至少3个，只要正常的节点数 >= n+1，Ceph 的 Paxos 算法就能保证系统的正常运行。
- MON_CLOCK_SKEW：mon节点时钟偏移，会有不可控的情况出现。
- OSD_DOWN：OSD无法访问，对应ceph-osd进程停止。
- OSD_FULL：对应OSD写到阈值，无法写入到对应OSD。
- OSD_BACKFILLFULL：对应OSD接近阈值，无法重平衡到对应节点。
- OSD_NEARFULL：OSD整体即将达到阈值，需要进行扩容操作。
HEALTH_ERR：存储池不可用，存储将会出于保护机制，禁止访问，会导致业务中断。
OSD运维实践
对于OSD或MON存储出现问题，可通过查看日志以及相对应的ERR代码，缩小排查范围。查看OSD/MON节点异常下线的错误码的日志路径如下： OSD：/var/log/ceph/ceph-osd.$id.err
MON：/var/log/ceph/ceph-mon.$id.err
OSD问题原因可以通过上述错误码，而后通过下表含义进行处理。
错误码的含义如下所示：
| 错误码 | 故障原因 | XMSD默认行为 |
|---|---|---|
| 5000001. ERROR_DISK_EIO | 磁盘介质错误 | 1 小时内连续 5 次出现该错误，判定为硬盘损坏（4.2.300.3以后，出现一次不再拉起） |
| 5000002. ERROR_NIC_DOWN | 网卡down或者网线被拔 | 拉起间隔是 （1、2、4、8、16）分钟，随后一直保持16分钟 |
| 5000003. ERROR_DISK_SLOW | 磁盘慢导致osd主动shutdown | 1 小时内连续 5 次出现该错误，判定为硬盘损坏 |
| 5000004. ERROR_NET_MARKDOWN_TOO_MANY | 10分钟内被markdown次数超过5次 | 拉起间隔是 （1、2、4、8、16）分钟，随后一直保持16分钟 |
| 5000005. ERROR_THREAD_TIMEOUT | osd内部线程超时shutdown | 拉起间隔是 （1、2、4、8、16）分钟，随后一直保持16分钟 |
| 5000006. ERROR_PROGRAM | 程序assert导致osd离线 | 拉起间隔是 （1、2、4、8、16）分钟，随后一直保持16分钟 |
| 8000000. ERROR_HEAVY_SLOW_IO_BASE | slow io导致的osd离线 | 拉起间隔是 （1、2、4、8、16）分钟，随后一直保持16分钟 |
| 8000002. ERROR_HEAVY_SLOW_IO_LOCAL_DISK | 本地磁盘慢 导致的heavy slow io严重超时 | 1 小时内连续 5 次出现该错误，判定为硬盘损坏 |
| 8000004. ERROR_HEAVY_SLOW_IO_CLUSTER | 集群问题（osdmap版本，pg , 对象状态问题等）导致的heavy slow io严重超时 | 拉起间隔是 （1、2、4、8、16）分钟，随后一直保持16分钟 |
| 8000008. ERROR_HEAVY_SLOW_IO_SYSTEM | 系统资源不足（缺少内存， CPU高占用等）导致的heavy slow io严重超时 | 拉起间隔是 （1、2、4、8、16）分钟，随后一直保持16分钟 |
OSD的离线拉起策略
1.在过去"一小时"(DiskIOErrorTimeout)，OSD 进程"连续 5 次" (DiskIOErrorCount) 退出原因都是以上提到的错误码时，则认为这个 OSD 的介质已经损坏。
- 数据库中，OSD 会记录相关退出的开始时间和连续发生次数。
- 当达到阈值时，标记 OSD 对应的硬盘的 disk.Status 为 dead ，并发出坏盘告警
- 从此，不再拉起这个硬盘，即使这个硬盘还能被识别到。
- 如果未达到次数之前超时，会重置之前记录的时间和次数并重新开始记录。
OSD运维最佳实践
OSD离线的现象以及对应的原因
多个osd离线上线
该问题一般由节点负载，raid卡问题以及缓存盘问题引起。
大量osd离线上线
该问题一般由存储网络问题引起。
单个osd离线上线
该问题一般由单个磁盘问题引起。
运维操作
对于OSD离线可以通过下列关系图进行分析处理。
